|
|
|
|
|
|
|
client is worried. Hello, you still there? You finally advise her that you could plan to implement the most important behavior and features in the initial increments, rolling out the remaining behaviors in successive increments. The first increment could be installed within three to four months, depending on how smoothly the iterations go through analysis, design, and construction. That explanation seems to do the trick. Well, though I'd like to have all my required functionality in place during that same time period, I also don't want to disrupt my operations with a low-quality system. Let's go with that plan and see how it goes. You agree and offer to fax her a copy of the requirements, as well as a consulting agreement for her to sign and return, which she later does. |
|
|
|
|
|
|
|
|
In Table 2.1 on Day 2, Fundamental Object-Oriented Analysis, you created a list of candidate classes, based on the initial problem statement. Recall that a problem statement is the requirements document that provides the foundation for all your project's models and other object-oriented artifacts. That list of candidate classes includes Teller, BankAccounts, and Account. Throughout this chapter, you will elaborate through the artifacts of design, including the interaction diagrams (sequence and collaboration) and class models. These artifacts will not only help you develop your system but also help you provide full explanations of the project's progress to your client. |
|
|
|
|
|
|
|
|
The Three Amigos of Object Technology |
|
|
|
|
|
|
|
|
These days there are many flavors of object-oriented design in the OO community. This section briefly introduces the most pervasive methodologies that include design processes. They are the following: |
|
|
|
|
|
|
|
|
Object-oriented software engineering (Objectory) |
|
|
|
|
|
|
|
|
Object Modeling Technique (OMT) |
|
|
|
|
|
|
|
|
Object-Oriented Software Engineering (Objectory) |
|
|
|
|
|
|
|
|
Noted OO methodologist Ivar Jacobson is the brains behind the Objectory method. Because of its ease of use and effectiveness in accurately representing document and model requirements (via the use-case model), it has become the foundation for object-oriented design efforts in general. However, Jacobson also offers the object-oriented software engineering (OOSE) approach to software construction (or design and programming). |
|
|
|
|
|
|
|
|
The OOSE design approach models the behavior of the system, as documented by the use cases, into logical parts (classes). At the core of the design model in OOSE are three types of classes (whose instances are objects): |
|
|
|
|
|